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AUTO-DISCOVERY OF NETWORK CONFIGURATION 

CROSS REFERENCE TO RELATED APPLICATIONS 

This application is related to U.S. Application No. , entitled "Virtual 

Network Configuration Verification," filed concurrently with the present application. 

FIELD OF THE INVENTION 

The present invention relates to communication networks and, in particular, to 
methods and apparatus for discovering information about the topology of a network. 

BACKGROUND OF THE INVENTION 

In networks, especially large networks, it is difficult to accurately determine the 
current configuration of a network. Determining the configuration of a network 
typically involves understanding the arrangement of nodes in the network. Having 
accurate information about the configuration of a network may be important for 
planning, testing, and trouble-shooting of the network. 

One aspect of configuration is the topology of a network. The topology of a 
network may change frequently as nodes are added, removed, modified, and 
upgraded. The topology may also change when links connecting the nodes in the 
network are added or removed. 

Conventionally, a network administrator must manually track these and other 
changes to the configuration. Unfortunately, manual tracking is cumbersome and 
prone to errors and becomes increasingly difficult as the size of a network increases. 
This frequently causes the network configuration to become unclear for long periods of 
time until the manual tracking methods catch up with the network conditions. 
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It is therefore desired to provide methods and apparatus that overcome these 
and other shortcomings of the prior art. 

SUMMARY OF THE INVENTION 

5 Accordingly, methods and apparatus are provided to determine configuration of 

at least a portion of a network. Based on status information from nodes in the portion 
of the network, respective labels that indicate one or more virtual connections 
traversing the nodes are determined. At least one link, such as between two nodes in 

E: a subset of the nodes, is identified based on the respective labels. The configuration 

W of the portion of the network is then determined based on the identified link. 

In accordance with another aspect of the present invention, methods and 

1 apparatus are provided to determine a configuration of a node in a network. Based on 
status information from the node and at least one other node in the network, 
respective labels that indicate one or more virtual connections traversing the node are 

15 determined. At least one link between the node and the other node is identified based 
on the respective labels. The configuration of the node is then determined based on 
the identified link. 

Additional features and advantages of the invention will be set forth in part in 
the description which follows, and in part will be obvious from the description, or may 
20 be learned by practice of the invention. The features and advantages of the invention 
will be realized and attained by means of the elements and combinations particularly 
pointed out in the appended claims. 

It is to be understood that both the foregoing general description and the 
following detailed description are exemplary and explanatory only and are not 
25 restrictive of the invention, as claimed. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporated in and constitute a part of 
this specification, illustrate embodiments of the invention and together with the 
description, serve to explain the principles of the invention. 

In the Figures: 

Fig. 1 illustrates a system, in accordance with methods and apparatus 
consistent with the present invention; 

Fig. 2 illustrates a block diagram of a server, in accordance with 
methods and apparatus consistent with the present invention; 

Fig. 3 illustrates a block diagram of a node, in accordance with methods 
and apparatus consistent with the present invention; 

Fig. 4 illustrates a table in a configuration database, which a server uses 
to identify one or more links between nodes, in accordance with methods and 
apparatus consistent with the present invention; and 

Fig. 5 illustrates the steps that a server may perform to determine a 
configuration of a network, in accordance with methods and apparatus consistent with 
the principles of the present invention. 

DESCRIPTION OF THE EMBODIMENTS 

Reference will now be made in detail to exemplary embodiments of the 
invention, examples of which are illustrated In the accompanying drawings. Wherever 
possible, the same reference numbers will be used throughout the drawings to refer to 
the same or like parts. 

Fig. 1 illustrates a system 100, in accordance with methods and apparatus 
consistent with the principles of the present invention. As shown, system 100 
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comprises a network 102, a server 104, and a configuration database 106. Network 
102 may include an interconnected group of nodes capable of sharing information. 
Network 102 may include, for example, a wide area network (WAN), or a local area 
network (LAN). Network 1 02 may be Implemented using a variety of technologies 
5 alone or in combination, including wireline technologies, such as, telephone, fiber optic 
cables, etc., and wireless technologies, such as, radio frequency (RF), satellite, 
microwave. Furthermore, network 102 may support a variety of protocols including 
Internet Protocols (IP), Asynchronous Transfer Mode (ATM), Frame-Relay, etc. 

Network 1 02 may include nodes 1 08, 1 1 0, 1 1 2, and 1 1 4 that serve as points of 
1-0 connection. Although Fig. 1 illustrates four nodes inside network 102, any number of 

'-■4 

:5 nodes may be interconnected across network 1 02, including nodes external to 
=- network 102. Nodes 108, 1 10, 1 12, and 1 14 may be implemented as a switch, or 
router. 

=- Nodes 1 08, 1 1 0, 1 1 2, and 1 1 4 may include cross-connect tables 116, 1 1 8, 1 20, 

15 and 122, respectively. Cross-connect tables 1 16, 1 18, 120, and 122 indicate virtual 
connections traversing nodes 108, 1 10, 1 12, and 1 14, respectively. A virtual 
connection refers to any type of logical connection traversing a node, such as an IP 
multiprotocol label switching ("MPLS") label switched path, an ATM virtual circuit, or a 
Frame-Relay virtual circuit. For example, cross-connect tables 1 16, 1 18, 120, and 
20 122 are shown storing information indicating ATM virtual connections each having 
labels based on a virtual path identifier ("VPI") and a virtual channel identifier ('VCI"). 
However, one skilled in the art would understand that cross-connect tables 116, 118, 
120, and 122 may be modified to accommodate other types of communications, such 
as a MPLS label switched path, or Frame-Relay virtual circuit. 
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Nodes 108, 110, 112, and 114 may be Interconnected by one or more links, 
where a link may include a patli, either physical or logical, that defines a specific 
communication channel or circuit between one or more nodes. A physical link may 
relate to the electrical and mechanical components embodying the communications 
5 channel or circuit. A logical link may be viewed as an abstraction of one or more 
underlying physical links representing the connectivity, between two nodes. The 
physical and logical links between nodes 108, 110, 112, and 114 may be based on the 
respective physical and logical topologies. A physical topology of network 102 
a corresponds to a representation of the physical links. A logical topology of network 
Ijo 102 is an abstract representation based upon the logical links. Configuration 
9 information for network 102 may include any information Indicating the physical 

topology or logical topology of network 1 02. 
y Server 104 may provide operations support for network 1 02, such as for 

O configuration management, provisioning, testing, billing, monitoring, and other 
15 management functions. Server 104 may be implemented as a general-purpose 
computer using known hardware and software. 

Configuration database 106 may store for information relating to the 
configuration of network 102, such as information relating to the physical and logical 
topologies of network 102. Configuration database 106 may be implemented using 
20 known hardware and software, such as the ORACLE product family provided by 
Oracle Corporation, the DB2 product family provided by International Business 
Machines ("IBM") Corporation, or products from the Sybase Corporation. Although 
shown directly connected to server 104, configuration database 106 may be integrated 
with server 1 04, or may be remotely connected across a network to server 1 04. 
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Fig. 2 illustrates a block diagram of server 104, in accordance with methods 
and apparatus consistent with the principles of the present invention. Server 104 may 
comprise an I/O port 200, a Simple Network Management Protocol (SNMP) manager 
202, and a network management application 204. I/O port 200 may provide an 
interface to network 102. Although server 104 is shown with one I/O port, any number 
of ports may be implemented. 

SNMP manager 202 may poll and interpret status information from nodes 108, 
110, 1 12, and 114. In one embodiment, SNMP manager 202 may use the SNMP 
protocol to access status information, such as Management Information Base ("MIB") 
parameters from nodes 108, 1 10, 112, and 114. RFC-1157, J. Case et al., "A Simple 
Network Management Protocol (SNMP)," (1990), describes, inter alia, the SNMP 
protocol and a MIB and is incorporated herein by reference in its entirety. For 
example, SNMP manager 202 may query, get responses, set variables, and 
acknowledge information to and from nodes 108, 110, 112, and 1 14 using the 
following SNMP operations: get(); get nextQ; get responseQ; set(); and trapQ. SNMP 
manager 202 may use the "gef operation to retrieve status information. SNMP 
manager 202 may use the "get next" operation to iteratively retrieve a series of status 
information messages from cross-connect tables 11 6, 1 1 8, 1 20, and 1 22 over a series 
of SNMP messages. The "get response" operation may be used to respond to a "get" 
operation. SNMP manager 202 may use the "set' operation to alter a variable or 
parameter in nodes 108, 1 10, 1 12, and 1 14. The "trap" operation allows either SNMP 
manager 202 or nodes 108, 1 10, 1 12, and 1 14 to specify an SNMP event in response 
to an alarm condition. 

Alternatively, SNMP manager 202 may use other network management 
schemes alone or in combination with the SNMP protocol. For example, SNMP 


APP 1403 

manager 202 may use IP utilities, such as pings, traceroutes, and zone transfers. In 

addition, SNMP manager 202 may use ATM operations and maintenance ("OAM") 

cells. Furthermore, proprietary schemes from particular manufacturers may also be 

incorporated into SNMP manager 202. 
5 Network management application 204 may provide analysis functions based on 

the status information, such as, MIB parameters received by SNMP manager 202. 

Functions supported by network management application 204 may include one or 
i.^ more of the following: providing topology maps of network 1 02; a user interface to 
is interact with nodes 1 08, 11 0, 11 2, and 1 1 4; various displays indicating the status of 
rtp nodes 108, 1 10, 1 12, and 1 14; and a compiling function used in conjunction with 
C configuration database 106 to store and access MIB parameters. Network 

management application 204 may be implemented using known software, such as the 
n NETVIEW product family provided by IBM Corporation, or the OPENVIEW product 
r family from the Hewlett Packard ("HP") Company. Although Fig. 2 shows one network 
15 management application, one skilled in the art would understand that multiple network 

management applications and SNMP managers may be implemented in a single 

server or across multiple servers coupled together. 

Fig. 3 illustrates a block diagram of node 1 10, in accordance with the methods 

and apparatus consistent with the principles of the present invention. As shown, node 
20 110 may comprise an I/O port 302, an SNMP agent 304, and a MIB memory 306. 

I/O port 302 may provide an interface to network 102. Although node 1 10 is 

shown with one I/O port, any number of ports may be implemented. In addition, node 

110 may include a management port (not shown) to send and receive status 

information, such as SNMP protocol messages. 
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SNMP agent 304 may maintain and provide status information for node 110. 
For example, SNMP agent 304 may perform one or more of the following: retrieve and 
store MIB parameters in MIB memory 308; respond to queries from SNMP agent 202; 
and provide information in response to an event such as an alarm condition. SNMP 
agent 304 may also allow node 110 to act as a proxy for another node. When acting 
as a proxy, node 110 may use non-SNMP communications such as proprietary 
messages to communicate with the other node. Upon receiving the status information 
from the other node, node 110 may then translate and fonward this status information 
in the form of SNMP protocol communications. SNMP agent 304 may be 
implemented using known software and hardware. 

MIB memory 306 may store status information, such as MIB parameters 
collected by SNMP agent 304. A wide variety of information may be stored in MIB 
memory 306 including information, such as cross-connect tables; address information 
of communications traversing node 110; error counts; and on/off status. MIB memory 
306 may also store other types of status information, such as traffic statistics for node 
110. 

Fig. 4 illustrates a table 400 in configuration database 106, which server 104 
may use to identify one or more links between nodes. As shown, table 400 may 
comprise rows 401 , 403, and 405 and columns 402, 404, 406, 408, 410, 412, and 414. 
Column 402 may include a label, such as a "cardinality," to indicate virtual connections 
traversing a node. A cardinality may refer to a value representing a quantity, such as 
the number of unique virtual path identifiers ("VPI") found in a portion of a cross- 
connect table for a node. In particular, table 400 may comprise rows 401 , 403, and 
405 to indicate cardinality values of 5, 6, and 7, respectively. 
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Column 404 may include an Indicator to note the cardinality associated with 
node 110. For example, based on information in cross-connect table 120, node 110 
may support virtual connections having VPIs of 17, 17, 34, 55, 77, 200, and 232. Of 
these VPIs, there are six unique values (i.e., since the VPi value 17 repeats), and 
hence, node 110 may have a cardinality of 6. Similarly, columns 406, 408, 410, 412, 
and 414 may also indicate respective cardinalities of nodes 110, 112, and 114. As 
shown in Fig. 4, node 108 may have cardinalities of 7 and 5 (i.e., since node 108 has 
two ports). Node 112 may have a cardinality of 5 and node 114 has cardinalities of 6 
and 7 (i.e., since node 114 also has two ports). 

Alternatively, table 400 may include labels other than a cardinality. For 
example, table 400 may include labels based upon virtual path identifiers (VPI) or 
virtual channel identifier (VCI) for ATM virtual connections, a data link connection 
identifier ("DLCI") for Frame-Relay virtual connections, or MPLS labels for IP MPLS 
label switched paths. Any label that identifies a virtual connection traversing a node 
may also be used. 

In addition, table 400 may also include a portion of cross-connect tables 116, 
118, 120, and 122. For example, server 104 may scroll through a portion of cross- 
connect tables 1 16, 1 18, 120, and 122 to determine the configuration of network 102. 
The size of the portion may be predetermined, such as 256 entries, or may vary as the 
configuration of network 102 is discovered. The entries in each of the portions of 
cross-connect tables 1 16, 1 18, 120, and 122 may then be compared to determine the 
configuration of network 102. 

Fig. 5 illustrates the steps that server 1 04 may perform to determine a 
configuration of network 1 02, in accordance with methods and apparatus consistent 
with the principles of the present invention. In one embodiment, server 1 04 retrieves 
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portions of cross-connect tables 1 16, 118, 120, and 122 from nodes 108, 1 10, 1 12, 
and 114, respectively (stage 500). For example, SNMP manager 202 may use a 
series of "get next" operations to query nodes 108, 110, 1 12, and 1 14 for their 
respective cross-connect tables 1 1 6, 1 1 8, 1 20, and 1 22. Nodes 1 08, 1 1 0, 1 1 2, and 
114 may then reply using "get response" messages. SNMP manager 202 may 
provide this information to network management application 204, which may then 
compile the portions of cross-connect tables 116, 1 18, 120, and 122 into table 400. 

Network management application 204 may determine respective labels for 
each virtual connection traversing nodes 1 08, 1 1 0, 1 1 2, and 1 1 4 (stage 502) . For 
example, as described in detail with respect to Fig. 4, network management 
application 204 may calculate respective cardinalities for nodes 108, 1 10, 1 12, and 
1 14 based on information compiled in table 400. 

Network management application 204 may compare the respective labels 
across the rows of table 400 to determine which of nodes 108, 1 10, 1 12, and 1 14 are 
interconnected by links (stage 504). Network management application 204 may then 
determine the number of label matches found in table 400 (stage 506). For example, 
as shown in Fig. 4, network management application 204 may determine matches 
based on respective cardinalities. Alternatively, network management application 204 
may determine matches by directly comparing virtual connection labels, such as 
virtual path identifiers (VPI) or virtual channel identifiers (VCI) for ATM virtual 
connections, a data link connection identifier ("DLCI") for Frame-Relay virtual 
connections, or MPLS labels for IP MPLS label switched paths. 

If no matches are found, then network management application 204 may report 
a possible configuration ambiguity (stage 508). For example, network management 
application 204 may report that the current portion of cross-connect tables 1 16, 1 18, 
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120, and 122 are 0, nodes 108, 110, 1 12, and 1 14 are not connected to each other, or 
nodes 108, 110, 112, and 114 are misconfigured. 

If matches are found, then network management application 204 may 
determine whether the number of matches exceeds a threshold value, such as a two 
5 matches (stage 51 0). If the numbers of matches do not exceed the threshold value, 
then network management application 204 may identify a link between the 
corresponding nodes (stage 512). For example, based on the respective cardinalities 
shown in table 400, node 1 08 may have links to nodes 1 1 2 and 1 1 4, and node 1 1 0 

y may have a link to node 114. In addition, network management application 204 may 

ho then indicate these links in configuration database 206. 

fj if the number of matches exceeds a threshold value, such as two matches, 

then network management application 204 may determine whether more portions of 

O 

h cross-connect tables 1 1 6, 1 1 8, 1 20, and 1 22 may be retrieved (stage 514). If there 
are not more portions of cross-connect tables 1 16, 1 18, 120, and 122, which may be 

"f5 retrieved, then network management application 204 may report an ambiguity (stage 
516). For example, network management application 204 may assume that a link 
connects two nodes and, thus, may interpret more than two matches to be a 
configuration ambiguity. 

If there are more portions of cross-connect tables 1 16, 1 18, 120, and 122, 

20 which may be retrieved, network management application 204 may then cause sen/er 
104 to proceed to subsequent portions of connectivity tables 1 16, 1 18, 120, and 122 
and conduct a next iteration beginning again at stage 500 to resolve the ambiguity. 

Other embodiments of the invention will be apparent to those skilled in the art 
from consideration of the specification and practice of the invention disclosed herein. 
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It is intended that the specification and examples be considered as exemplary only, 
with a true scope and spirit of the invention being indicated by the following claims. 
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